keywords

    Although resilience is widely recognized in related disciplines such as Computer Science [42], Contingencies and Crisis Management [12], or Safety Engineering [25], there is an apparent incongruity between the level of interest paid by business managers and the attention that organizational and IS scholars have given to resilience. Today, only a limited number of IS resilience research exists [32]. This research gap is surprising, since resilience is often said to be a combination of social or organizational and technical qualities and therefore a research topic well suited for IS research. Hence, we provide a brief overview of existing work on resilience in IS research in order to derive key concepts as a foundation to gather requirements for our proposed resilience detection framework.

    Based on a literature review, we developed a resilience management cycle [32] (depicted in Figure 1) for automated support for resilient BPM according to the well-established BPM lifecycle. The cycle contains four phases adapted primarily from [8] and [15], beginning with (i) Detection in order to identify failures, potential weaknesses and exceptional process executions. (ii) The purpose of Diagnosis and Evaluation is to collect and assess vulnerabilities, and consequently to determine a set of intervention types. (iii) The next stage covers Treatment and Recovery, including the actual selection and implementation of supportive actions and automatic corrections. (iv) Finally, the phase of Escalation and Institutionalization guarantees enrichment or revision of the current knowledge base, and aims to establish and facilitate an organization-wide resilience culture.

    In accordance with the resilient management cycle, it is natural to focus on the detection stage first. Hence, in order to detect operational resilience, we aim to automatically identify failures (cause a loss of acceptable service [31]), exceptional process executions [25], and potential weaknesses (such as interdependencies and bottlenecks [43,41]) by means of forensic techniques. Before we describe the PREDEC framework and its modules, we first review current research and identify several research gaps to formulate our research agenda.

Status Quo and Shortcomings

    The majority of recent work on IS resilience and related research remains on a pure conceptual level. For example, a recent literature review on IS resilience has been carried out by [32], proposing an IS research agenda on resilience and resilience management. Through a comprehensive collection and evaluation of relevant literature, the authors identified and consolidated a myriad of limitations and research gaps: Resilience is rarely acknowledged in theoretical discussions of IS domains, which results in a lack of understanding of antecedents, principles and outcomes of IS resilience. The current state of art is dominated by conceptual or anecdotal contributions. This results not only in a lack of empirical work to validate IS resilience, but also in the lack of systematic resilience requirements for either IS design or methodological approaches. Moreover, current attempts to operationalize IS resilience are still on a very immature stage and impede both empirical evaluation of current research work as well as the actual implementation and validation of techniques and IS artifacts to make resilience operational. Finally, the paper discusses the integration of resilience and BPM [32]: Although the management of risks in BPM has been well recognized in the past few years, the link between resilience and BPM is largely neglected so far, leading to an absence of frameworks and approaches.

    Interestingly, current literature reviews on so-called risk-aware BPM by [26] or [36] show, that the vast majority of contributions concentrate on design-time risk-management in BPM systems, while approaches at run-time and the exploitation of process-related log files a posteriori are largely neglected. But as highlighted in the previous section, resilience focuses on run-time and a postiori analytics in order to manage consequences of risks, as also illustrated in Figure

    Recent frameworks for resilient BPM such as [8] tend to state very abstract implementation suggestions. For example, [8] and [15] provide a set of fundamental requirements for supporting resilient BPM. While these works capture basic requirements for resilient IS design, they lack empirical validation, concrete implementation guidelines, as well as artifacts to support the implementation of resilience in IS. Thus, concrete measures are mostly missing, leading to inefficient or even misleading resilience strategies. Effective and cost-efficient tools that could be used for the (semi-)automated detection of BPM resilience are missing. Furthermore, existing methods provide decision makers with limited intuitive support-tools at high personnel costs and, thus, fail to assist them in enhancing and maintaining resilience of BPM.

    We pursue to address these essential, yet open, issues by providing a new approach to supporting decision makers in automatically detecting the occurrence of hazards, and therefore addressing the sensitivity and resilience of information infrastructures.

      In order to answer these research questions we attempt to make the following contributions. We aim at: (i) Combining and systematizing the related but still disconnected fields of IS resilience and process-orientation. The development of a BPM resilience cycle corresponds with the BPM lifecycle and enables and proposes how to build and enhance resilient BPM. (ii) Providing event log specifications to enable process-centric resilience detection. The requirements and measures developed serve as basis for eliciting and subsequently assessing structural characteristics of information infrastructures. (iii) Making a major step beyond the state of the art by introducing a methodology that allows for a (semi-)automated conformance check based on resilient BPM principles. (iv) Providing decision makers with a comprehensive methodology for analyzing and diagnosing the resilience of information infrastructures and thereby generating meaningful insights and evidences in an intuitive and economic manner. These contributions serve as groundwork for supporting subsequent steps of the resilience management cycle, such as escalation and institutionalization. (v) Rendering the tedious work of manually combing the knowledge from best practice guidelines with the actual infrastructure obsolete. (vi) Enabling the objective detection of vulnerabilities on executed processes instead of intended process models. (vii) Setting the ground for subsequent phases on the BPM resilience cycle, such as diagnosis and evaluation, treatment and recovery, as well as escalation and institutionalization.